НАЗВА¶

inetd - керівник сервісами для Інтернету

СТИСЛИЙ ОГЛЯД¶

inetd [-d] [-R частота] [файл конфігурації]

ОПИС¶

inetd повинен запускатись під час завантаження системи скриптом /etc/rc (дивіться rc(8)). Після цього цей демон прослуховує певні сокети інтернету щодо під'єднань. Якщо виявлене сполучення на одному з сокетів, inetd вирішує якому сервісу належить даний сокет і викликає відповідну програму для опрацювання запиту. Після закінчення дії програми, inetd продовжує прослуховувати сокет (окрім випадків, описаних нижче). По суті, inetd дозволяє, запустити лише один демон, який в свою чергу викликатиме інші, таким чином зменшуючи навантаження на систему.

Програма візьме наступні опції:

-d

Увімкне зневадження.

-R частота

Вказує максимальну кількість разів, які дозволено викликати певний сервіс впродовж однієї хвилини. За замовчуванням - без обмежень. Частота 0 також означає необмежену кількість викликів.

По виконанню, inetd зчитує власний файл конфігурації, типово /etc/inetd.conf. Цей файл повинен містити по одному запису у кожному полі рядка. Записи можна розділяти кроком табуляції або пробілом. Коментарі позначаються знаком `#' на початку рядка. Поля повинні бути заповненими наступною інформацією:

Для сервісів, базованих на Sun-RPC, поля повинні містити наступне:

Для сервісів Інтернету, перше поле може мати також вказаним адресу хосту у вигляді префіксу, розділеного від назви сервісу двокрапкою. Якщо використана така нотація, то рядок поперед сервісом вказуватиме яку локальну адресу використовувати inetd для даного сервісу. Багаточисельні локальні адреси можна також вказувати на одному рядку, якщо розділити їх комами. Числові IP-адреси можна застосовувати так само як символічні назви хостів. Символічні назви розв'язуються за допомогою gethostbyname(3). Якщо хостові належать багаточисельні адресні відображення, inetd створить сокет для прослуховування для кожної окремої адреси.

Поодинокий знак `*' означає INADDR_ANY, тобто "всі локальні адреси". Щоб запобігти багатократного внесення тієї самої адреси в поля, можна внести її окремо, з двокрапковим закінченням, на одному з рядків, без решти полів. Це заставить inetd запам'ятати цю адресу і використовувати для решти полів без відвертої вказівки хосту (до наступного подібного рядка, або кінця файлу). Типово, ви знайдете рядок

на самому початку inetd.conf; таким чином, стандартні конфігураційні файли (що не містять вказівників хосту у першому полі), буде інтерпретовано традиційним способом, коли всі сервіси очікуються всіма локальними адресами.

Поле з назвою сервісу повинне містити чинну назву з файлу /etc/services. Для "внутрішніх" сервісів (описаних нижче) назва сервісу повинна співпадати з офіційними назвами (тобто першим записом з /etc/services). У випадку ж сервісів на базі Sun-RPC, це поле повинне співпадати з одним з записів з /etc/rpc. Частина, що знаходиться справа від `/' являється номером версії RPC. Це може бути як єдиний числовий аргумент, так і обсяг версій. Інтервал версій позначається починаючи з меншої і закінчуючи більшою: `rusers/1-3'.

Тип сокету може бути одним з: `stream', `dgram', `raw', `rdm' або `seqpacket', в залежності від того, чи це потоковий, детаграмний, необроблений, надійно доставлених повідомлень (reliably delivered message) чи сокет послідовних пакетів.

Протокол повинен бути дійсним протоколом з /etc/protocols. Прикладом, `tcp' або `udp'. RPC-базовані сервіси повинні вказуватись як `rpc/tcp' або `rpc/udp'. Просто `tcp' або `udp' будуть розглядатися як "TCP або UDP через стандартну версію IP". На даний момент стандартною є IPv4, але незабаром може помінятись на IPv6. Якщо вам необхідно явно вказати IPv4 або IPv6, використайте щось на зразок `tcp4' або `udp6'.

Поле wait/nowait вказує inetd, чи очікувати повернення результату від серверної програми, чи продовжувати обробляти наступні під'єднання на сокеті. Якщо детаграмний сервер після сполучення на сокеті з клієнтом, звільняє сокет, тож inetd зможе продовжувати отримувати повідомлення на сокеті, такий сервер вважається "мультипотоковим", і повинен бути нотованим як `nowait'. Детаграмні сервери, які обробляють за раз всі детаграми, що надійшли на сокеті і зрештою завершує строк своєї дії, вважаються "однопотоковими" серверами і повинні вживатись з `nowait' записом. comsat(8), biff(1) і talkd(8) є саме прикладами останнього типу детаграмного серверу. tftpd(8) являється виключенням; це детаграмний сервер, який встановлює псевдо-з'єднання. Його необхідно помітити як `wait', щоб запобігти стану перегонів. Сервер читає перший пакет, створює новий сокет і відгалужується і виходить, щоб дозволити inetd перевірити нові запити щоб запустити новий сервер на цьому сокеті. Необов'язковий суфікс максимум (розділений від `wait' або `nowait' крапкою) вказує на максимальне число серверів, які inetd може запустити на протязі 60-и секунд. За замовчуванням не існує обмежень. Встановлення цього значення, власне, навпаки може полегшити зловмиснику здійснити атаку по відмові від обслуговування (denial of service). Тож цей параметр не рекомендовано задавати.

Потокові сервери, як правило позначаються як `nowait', але якщо тільки один серверний процес обробляє багаточисельні під'єднання, його може бути помічено як `wait'. Основний сокет, в останньому випадку, буде передано як fd 0 (дескриптор файлу під номером 0) серверу, який повинен буде прийняти вхідне під'єднання. Сервер, в кінці кінців, повинен буде завершити строк своєї дії і вийти, якщо залишиться більше активних під'єднань. inetd після цього продовжить слухати на основному сокеті щодо наступних сполучень; саме тому сервер не повинен закривати сокет під час завершення своєї дії. inetd(8), в дійсності, є єдиним потоковим сервером, позначеним як `wait'.

Поле користувача повинне містити назву користувача, від чиєго імені сервер буде запущено. Це дозволяє надавати серверам менші права ніж root. Можна також додати необов'язкову назву групи, через крапку. Це також дозволяє серверному процесу числитись під відмінною від основної з поміж груп користувача, вказаних у файлі passwd. Якщо групу вказано і користувач не є root-ом, додаткові групи, асоційовані з цим користувачем все ще залишатимуться чинними.

Поле серверної програми повинне містити дійсний шлях до програми, яка буде виконана inetd після отримання запиту на сокеті. Якщо inetd надає цей сервіс внутрішньо, тоді це поле повинне містити `internal'.

Поле аргументів серверної програми повинне складатися (короткої) назви самої програми й аргументів, які за звичайних обставин, ми б надали на командному рядку. Якщо цей сервіс надається внутрішньо inetd, тоді це поле повинно містити `internal'.

inetd надає декілька простих сервісів внутрішньо, використовуючи власні вбудовані функції. Цими сервісами є `echo', `discard', `chargen' (генератор знаків), `daytime' (час у срийнятному для людини форматі) і `time' (машиночитаємий час у формі кількості секунд від півночі, 1 Січня 1900 року). Всі ці сервіси TCP-базовані. Про деталі щодо кожного з них, зверніться до відповідних RFC від Інформаційного Центру Мережі.

inetd перечитує свій файл конфігурації, при отриманні сигналу зависання SIGHUP. Таким чином, можна додати, змінити або усунути певні сервіси. inetd також створює файл /var/run/inetd.pid, що містить власний ідентифікатор процесу.

ВАДИ¶

Вказівники адрес хостів, хоч і концептуально зрозумілі сервісам RPC, не працюють цілком коректно. Це пов'язано з тим, що інтерфейс перетворювача портів, portmapper, не надає можливості реєстрації різних портів для того самого сервісу на різноманітних локальних адресах. Все працюватиме як слід лише за умови, що у вас не буде більше одного запису в inetd.conf для того самого сервісу RPC. (Пам'ятайте, що вказівник хосту за замовчуванням матиме дію для записів RPC без вказаної локальної адреси.)

`rpc' і `tcpmux' на IPv6 ще недостатньо тестовано. Підтримка Kerberos на IPv6 ще не перевірялась.

ДИВІТЬСЯ ТАКОЖ¶

comsat(8), fingerd(8), ftpd(8), rexecd(8), rlogind(8), rshd(8), telnetd(8), tftpd(8)

ІСТОРІЯ¶

Команда inetd вперше з'явилась у 4.3BSD. Підтримка сервісів, базованих на Sun-RPC, створена за зразком SunOS 4.1. Підтримка IPv6 і гек IPsec були втілені проектом KAME у 1999 році.

Переклав Віталій Цибуляк <vt@uatech.atspace.com>